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(54) Cataloging apparatus for facilitating the re-use of distributed objects in a distributed object 
system 



(57) A method, apparatus, and computer program 
product for selecting and reviewing a distributed object 
installed on a distributed object system is described. In 
one embodiment, the method of the invention includes 
generating a library of components corresponding to 
distributed objects on said distributed object system, in- 
cluding one component corresponding to the distributed 



object. Each of the components of the library includes 
information describing the distributed object to which the 
particular component corresponds. The contents of the 
library are displayed using a catalog interface device. 
The library is browsed using the catalog interface device 
to identify the component corresponding to the distrib- 
uted object, and is selected. At least a portion of the in- 
formation describing the distributed object is displayed. 
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Description 

BACKGROUND OF THE INVENTION 

1 . The Field of the Invention 

The present invention relates to the fields of distrib- 
uted computing systems, client-server computing and 
object-oriented programming. More specifically, the 
present invention includes a method and apparatus for 
creating object-oriented software applications for use on 
a distributed object system. 

2. The Relevant Art 

Object-oriented programming methodologies have 
received increasing attention over the past several 
years in response to the increasing tendency for soft- 
ware developed using traditional programming methods 
to be delivered late and over budget. Object-oriented 
programming methodologies focus on manipulating da- 
ta rather than procedures; thus providing the program- 
mer with a more intuitive approach to modeling real 
world problems. In addition objects encapsulate related 
data and procedures so as to hide that information from 
the remainder of the program by allowing access to the 
data and procedures only through the object's interface. 
Hence changes to the data and/or procedures of the ob- 
ject are relatively isolated from the remainder of the pro- 
gram. This provides code that is more easily maintained 
as compared to code written using traditional methods, 
since changes to an object's code do not affect the code 
in the other objects. In addition, the inherent modular 
nature of objects allows individual objects to be re-used 
in different programs. Thus, programmers can develop 
libraries of "tried and true" objects that can be used over 
and over again in different applications. This increases 
software reliability while decreasing development time, 
as reliable programming code may be used repeatedly. 

Object-oriented distributed systems are based up- 
on a client-server model, in which object-servers pro- 
vide interfaces to clients that make requests of the ob- 
ject-servers. Typically, these servers are objects con- 
sisting of data and associated methods. The clients ob- 
tain access to the functionalities of the object-servers 
by executing calls on them, which calls are mediated by 
the distributed system. When the object-server receives 
the call it executes the appropriate method and trans- 
mits the result back to the object-client. The client and 
object-server communicate through an Object Request 
Broker (ORB) which is used to locate the various dis- 
tributed objects and establish communications therebe- 
tween. 

Although the advantages to employing object-ori- 
ented programming methodologies through distributed 
object systems are significant, there remain major hur- 
dles to their implementation. In general, the goal of im- 
plementing the re-use of software during the program- 



ming process, even in the context of object program- 
ming, is difficult to achieve. Typically, programmers are 
reluctant to use code about which their understanding 
is minimal or even nonexistent. This is compounded in 

5 distributed object systems as the developer(s) of the 
code may not be easily reached to provide comments 
and instruction to the programmer whose task is to de- 
velop a new application. Thus ; although much useful 
code may be available to the programmer throughout 

10 the distributed object system that programmer may not 
be able to take full advantage of it, thus being forced to 
rewrite sections of code that have already been devel- 
oped. 

Present methodologies for sharing code are inade- 
15 quate in the distributed object model. Current methods 
for sharing object code include the use of shared librar- 
ies, publicly available directories of header files, and the 
wide-spread distribution of documentation (either elec- 
tronically or by hard copy). These methods, however, 
20 do not lend themselves well to a distributed object en- 
vironment in which the basic elements being manipulat- 
ed are not file-based but rather are interface-based. Al- 
so, methods for re-using objects in a distributed object 
system should seek to increase the user's sense of a 
25 "community" of programmers and the code they pro- 
duce. Thus, systems seeking to increase the re-use of 
objects in a distributed object system should facilitate 
the user's determination of an object's identity, its pur- 
pose, and its method of use. 
30 Another challenge to programming in a distributed 
object environment is the need to provide large amounts 
of "boilerplate" type computer code so that objects and 
applications developed for use in the distributed object 
system can function properly within that system; in par- 
35 ticular, the need to provide basic computer code struc- 
tures to enable ordinary objects (i.e., C++ objects) to 
function as distributed objects. In addition, however the 
programmer seeking to maximize the re-use of existing 
objects and computer code in the distributed objects 
40 system is faced with similar although slightly different 
challenges. When a programmer wishes to employ a ob- 
ject in an application being developed, the programmer 
must indicate basic information pertaining to the object 
such as calls to the object's factory and provide various 
45 initialization data. In addition, a variety of make files, 
header files, and library dependencies must be account- 
ed for in the code before that code is forwarded to ad- 
ditional facilities. Additional details that must be provid- 
ed by the programmer include various exception han- 
50 dling, debugging, and tracing support code. Again, al- 
though the methods and code required are generally 
known to those of skill in the art, the implementation of 
such routines is laborious, repetitive, and prone to error. 
Thus, the development of appropriately coded object 
55 applications is an extremely time consuming and pains- 
taking task. It wou Id therefore be preferable to automate 
the incorporation of such "housekeeping" code. 

Thus, it would be desirable to allow programmers 
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and other users the ability to create and install distribut- 
ed objects in a relatively transparent fashion so that ob- 
jects created in different programming languages and/ 
or objects residing on different computing platforms can 
be made available on distributed object systems without 
extensive re-invention of existing programming code, or 
placing an undue burden on the user. Solutions to these 
problems would facilitate the development of object-ori- 
ented applications and distributed object applications, 
by allowing the programmer to focus on the tasks that 
required real creative effort and minimize repetitive cod- 
ing and analysis. 

SUMMARY OF THE INVENTION 

The present invention provides methods, appara- 
tus, and computer program products described herein 
allow programmers to access and review distributed ob- 
jects already installed on a distributed object system to 
determine whether such pre-existing objects can be in- 
cluded in software that is under development. As will be 
described in greater detail herein, the methods, appa- 
ratus, and computer program products forfacilitating the 
re-use of distributed objects installed on a distributed 
object system, enhance the efficiency of the software 
construction process and the reliability of the code so 
produced. 

In one aspect, the present invention provides a 
computer-implemented method for selecting and re- 
viewing a distributed object installed on a distributed ob- 
ject system. In one embodiment, the method of the in- 
vention includes generating a library of components cor- 
responding to distributed objects on said distributed ob- 
ject system, including one component corresponding to 
the distributed object. Each of the components of the 
library includes information describing the distributed 
object to which the particular component corresponds. 
The contents of the library are displayed using a catalog 
interface device. The library is browsed using the cata- 
log interface device to identify the component corre- 
sponding to the distributed object, and is selected. At 
least a portion of the information describing the distrib- 
uted object is displayed. 

In one embodiment of the above-described method, 
displaying the contents of said library comprises provid- 
ing a display of at least a portion of the hierarchical di- 
rectory structure of the library. In another embodiment, 
the step of browsing said library of components com- 
prises selecting a file path using said display of said hi- 
erarchical directory structure of said library and display- 
ing representations of components located in said path. 
In still another embodiment, the representations com- 
prise icons ; and said step of selecting comprises making 
a selection action on an icon. 

In another aspect, the present invention provides a 
computer system for selecting and reviewing a distrib- 
uted object installed on a distributed object system. In 
one embodiment of the computer system provided by 



the invention, the system comprises a library of compo- 
nents corresponding to distributed objects on said dis- 
tributed object system, wherein each of said compo- 
nents includes information describing the distributed ob- 
5 ject to which the component corresponds. The library of 
components includes one component corresponding to 
the distributed object. The computer system of the in- 
vention further includes a library manager which is ef- 
fective to locate and retrieve said components. Finally 
10 a catalog interface device for displaying, reviewing and 
selecting said components in said library is provided. 
The catalog interface device is coupled with said library 
manager such that queries and selection actions made 
in said catalog interface device are communicated to 
15 said library manager. 

In one embodiment, the computer system of the in- 
vention further includes a component generator which 
is effective to generate components corresponding to 
selected, installed distributed objects in said distributed 
20 objects system. In a more specific embodiment, the 
component generator is coupled with the distributed ob- 
jects to which said components refer. In another embod- 
iment, the computer system of the invention includes a 
builder coupled with said component generator such 
25 that said components are generated when the distribut- 
ed objects to which the components refer are processed 
by said builder. In still another embodiment, the catalog 
interface comprises a graphical user interface. In a more 
particular embodiment, the catalog interface devices 
30 comprises a display of at least a portion of the hierar- 
chical directory structure of said library. 

In still another embodiment, the computer system 
provided by the present invention comprises a process- 
ing unit which is coupled to an input/output device. Ran- 
35 dom access memory is also coupled with the processing 
unit. A memory device is in communication with the 
processing unit. The memory device includes a distrib- 
uted object reference data structure and an associated 
component data structure, said component data struc- 
40 ture including presentation information, programmer in- 
formation, and tool information relating to said distribut- 
ed object data structure. In one embodiment, the com- 
puter system further includes a library of components 
contained in a library data structure residing in said 
45 memory device, said library of components including a 
library service effective to locate and retrieve said com- 
ponents in response to commands received from said 
input/output device. 

In yet another aspect, the present invention pro- 
50 vides a computer program product comprising a com- 
puter-usable medium having computer-readable pro- 
gram code embodied thereon for a component data 
structure, said component data structure being related 
to a distributed object data structure installed on a dis- 
55 tributed object system, and said component data struc- 
ture including presentation information, programmer in- 
formation, and tool information relating to said distribut- 
ed object data structure. 
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In one embodiment, the computer readable pro- 
gram code devices include code devices effective for 
generating the component in addition to generating a 
library of component data structures corresponding to 
distributed object data structures on said distribute ob- 
ject system, wherein each of said component data struc- 
tures includes information describing a distributed ob- 
ject data structure to which the component data struc- 
ture corresponds. This embodiment also includes com- 
puter readable program code devices configured to 
cause a computer to display the contents of the library 
using the catalog interface device to identify said distrib- 
uted object data structures, browsing said library of 
component data structures using said catalog interface 
device to identify said distributed object data structures, 
and displaying at least a portion of said information de- 
scribing said distributed object data structures. 

These and other aspects and advantages of the 
present invention will become more apparent when the 
Description below is read in conjunction with the accom- 
panying Drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Figure 1 is a schematic illustration of an object re- 
quest broker (ORB) in accordance with the present in- 
vention. 

Figure 2 is an illustration of a computer network in 
accordance with the present invention. 

Figure 3 is a schematic illustration of a computer 
system in accordance with the present invention. 

Figure 4 is a schematic illustration of a system for 
constructing object-oriented applications in a distributed 
object system in accordance with the present invention. 

Figure 5 is a schematic illustration of a hierarchical 
directory structure for storing, searching, and retrieving 
components corresponding to distributed objects in ac- 
cordance with the present invention. 

Figure 6 is an illustration of a graphical user inter- 
face for searching and examining components accord- 
ing to one embodiment of the present invention. 

DESCRIPTION OF SPECIFIC EMBODIMENTS 

Section 1 below describes the basic organization 
and operation of distributed object systems. Second 2, 
at page 11 below, describes the components, library 
services, and uses thereof, as provided by the present 
invention. 

1. PHYSICAL EMBODIMENTS AND BACKGROUND 
OF DISTRIBUTED OBJECT SYSTEMS 

The present invention employs various process 
steps involving data stored in computer systems. These 
steps are those requiring physical manipulation of phys- 
ical quantities. Usually, though not necessarily, these 
quantities take the form of electrical or magnetic signals 



capable of being stored, transferred, combined, com- 
pared, and otherwise manipulated. It is sometimes con- 
venient, principally for reasons of common usage, to re- 
fer to these signals as bits, values, elements, variables, 
5 characters, data structures, or the like. It should be re- 
membered, however, that all of these and similar terms 
are to be associated with the appropriate physical quan- 
tities and are merely convenient labels applied to these 
quantities. 

10 Further, the manipulations performed are often re- 
ferred to in terms such as identifying, running, or com- 
paring. In any of the operations described herein that 
form part of the present invention these operations are 
machine operations. Useful machines for performing 

15 the operations of the present invention include general 
purpose digital computers or other similar devices. In all 
cases, there should be borne in mind the distinction be- 
tween the method of operations in operating a computer 
and the method of computation itself. The present in- 

20 vention relates to method steps for operating a compu- 
ter in processing electrical or other physical signals to 
generate other desired physical signals. 

The present invention also relates to an apparatus 
for performing these operations. This apparatus may be 

25 specially constructed for the required purposes, or it 
may be a general purpose computer selectively activat- 
ed or reconfigured by a computer program stored in the 
computer. The processes presented herein are not in- 
herently related to any particular computer or other ap- 

30 paratus. In particular, various general purpose ma- 
chines may be used with programs written in accord- 
ance with the teachings herein, or it may be more con- 
venient to construct a more specialized apparatus to 
perform the required method steps. The required struc- 

35 ture for a variety of these machines will appear from the 
description given below. 

In addition, the present invention further relates to 
computer readable media which include program in- 
structions for performing various computer-implement- 

40 ed operations. The media and program instructions may 
be those specially designed and constructed for the pur- 
poses of the present invention, or they may be of the 
kind well known and available to those having skill in the 
computer software arts. Examples of computer reada- 

45 ble media include, but are not limited to. magnetic media 
such as hard disks, floppy disks, and magnetic tape; op- 
tical media such as CD-ROM disks; magneto-optical 
media such as floptical disks; and hardware devices that 
are specially configured to store and perform program 

50 instructions, such as read-only memory devices (ROM) 
and random access memory (RAM). Examples of pro- 
gram instructions include both machine code, such as 
produced by a compiler, and files containing higher level 
code that can be executed by the computer using an 

55 interpreter. 

A distributed object system 1 0 typically includes an 
Object Request Broker (ORB) 11 as is symbolically il- 
lustrated in Figure 1. ORB 11 provides location and 
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transport mechanisms and facilities necessary to deliver 
a call from a client to a servant (target object) and to 
return a response to the client. The client and servant 
may be located in the same process, in different proc- 
esses on the same machine, or on completely different 
machines. For the purposes of this discussion, client 20 
may be any code that invokes an operation on a distrib- 
uted object and thus may or may not take the form of a 
distributed object or a process. A distributed object may 
have a wide variety of representations. By way of exam- 
ple, the distributed object may be a C++ object that has 
been provided by an application developer. Alternative- 
ly, an implementation for a distributed object may be de- 
veloped within a visual application builder 15 as de- 
scribed in greater detail in Section 2 below. In brief : the 
visual application builder allows a developer to visually 
select existing object types from a catalog of object 
types available on the distributed object system and 
graphically connect the services provided by the select- 
ed objects to create a new implementation for an object. 

An object development facility 16 may be used to 
simplify the creation and the installation of distributed 
objects, in part, by "wrapping" or encapsulating devel- 
oper objects in distributed object code. As such, object 
development facility 16 may be used to transform a de- 
veloper object into an ORB object implementation 14. 
In this example, ORB object implementation 14 is pre- 
sented as a server as shown by its location in the dia- 
gram. A developer uses an interface definition language 
to define an interface for an ORB object, provides a de- 
veloper object implementation that implements that ob- 
ject's behavior, and then uses the object development 
facility 1 6 in order to produce an ORB object implemen- 
tation 14. At run time, an instance of this ORB object (a 
servant object) is created that will utilize this ORB object 
implementation 1 4. It should be appreciated that the ob- 
ject development facility may also be used to create ob- 
jects that take the role of clients at some point. 

Client 20 communicates with a servant by way of a 
stub 21 , a subcontract layer 36, possibly a filter 40, and 
a transport layer 38. Stub 21 includes a surrogate 22, a 
method table 24 and stub functions 25. Client 20 com- 
municates initially with surrogate 22 that appears to the 
client as the servant object. Alternatively, client 20 may 
communicate directly with the servant object through a 
dynamic invocation interface (DM) 26 instead of through 
surrogate 22, method table 24 and stub functions 25. 
Dynamic invocation interface 26 is used to enable cli- 
ents to construct dynamic requests. 

Subcontract layer 36 provides the functionality re- 
quired by an object in order to utilize subcontracts to 
implement various services (or features or object mech- 
anisms) named by a particular subcontract. A subcon- 
tract identifies a quality of service provided by the dis- 
tributed object system that may be utilized by an indi- 
vidual object. For example, a subcontract may identify 
that the feature of security is to be used for a particular 
object. Filter 40, if being used, may perform a variety of 



tasks, such as compression, encryption, tracing, or de- 
bugging, that are to be applied to communications to 
and from an object. Transport layer 38 operates to mar- 
shal, unmarshal and physically transport information to 
5 and from a servant that typically does not share the 
same process as a client. 

A standard implementation suite 28 (or object 
adapter) represents a set of subcontracts that interact 
with ORB objects 14 in identical ways, as for example 
10 object key management. It should be noted that a sub- 
contract may belong to multiple implementation suites. 
Also, implementation suites may utilize different sub- 
contracts. A skeleton ; that may take the form of either 
static skeleton 32 or dynamic skeleton 30, is used to 
15 transform requests into a format required by a servant 
object 78. Thus, skeletons 30 and 32 call an appropriate 
servant object 78. Static skeleton 32 is used to call in- 
terface-specific object implementations 14, while dy- 
namic skeleton 30 is used generically when interface- 
20 specific objects are not available. An ORB interface 34 
is the interface that goes directly to the ORB that is the 
same for all ORBs and does not depend upon an ob- 
ject's interface or object adapter. An ORB daemon 46 is 
responsible for ensuring that object servers are active 
25 when invoked by clients. 

Secure Protocol 42 is a secure interoperability pro- 
tocol that secures the internet inter-ORB protocol and 
helps to transmit information through transport layer 38 
in a secure fashion. This may mean integrity protection, 
30 confidentiality, etc. The internet inter-ORB protocol is a 
protocol that typically communicates between process- 
es on different machines. However, in some cases, the 
internet inter-ORB protocol may communicate between 
processes on the same machine. The security server 54 
35 is a security administration server that secures the serv- 
ices that are used between processes on different com- 
puters. 

Typecode/Any module 44 implements "Typecode" 
and "Any" objects. Typecode describes an Interface 
40 Definition Language (IDL) data type, allowing type de- 
scriptions to be transmitted between clients and servers. 
An instance of an IDL data type may be encapsulated 
by an Any object. An Any object refers to typecode of 
the encapsulated data, and a generic encoding of the 
45 data. 

An implementation repository 50 is used to store in- 
formation relating to object servers. Specifically imple- 
mentation repository 50 stores the information needed 
to start a server process. For example, implementation 
50 repository 50 stores information such as the location of 
the server program, any arguments to the program, and 
any environment variables to pass to the program, etc. 

Simple persistence 56 uses an Interface Definition 
Language (IDL)-defined type and the output from run- 
55 ning that IDL type through the IDL compiler, together 
with a portion of additional code so that an IDL-defined 
type can be read from, and written to, disk. A naming 
service 52 is used to name ORB objects. A client may 
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use naming service 52 to find a desired object by name. 
Naming service 52 returns an object reference, that in 
turn may be used to send request to that object. An In- 
terface Repository 48 (IFR) knows about all interfaces 
for all objects within the distributed object system. 

In an embodiment of the present invention, distrib- 
uted objects are located on one or more computers 
linked together by a computer network such as the net- 
work illustrated at 100 in Figure 2. As seen in the Figure, 
network 100 includes computer 102 which computer is 
coupled to a network 104. Network 104 can further in- 
clude a server, router or the like 106 in addition to other 
computers 1 08, 1 1 0 ; and 1 1 2 such that data and instruc- 
tions can be passed among the networked computers. 
The design, construction and implementation of compu- 
ter networks will be familiar to those of skill in the art. 

Computers 102, 106, 108, 110, and 112 are illus- 
trated schematically with respect to Figure 3 at 200. 
Each computer includes a processing unit 202 effective 
for performing computations, such as, but not limited to, 
a central processing unit (CPU), or multiple processors 
including parallel processors or distributed processors. 
Processor 202 is coupled with primary memory 204 
such as random access memory (RAM) and read only 
memory. Typically RAM includes programming instruc- 
tions and data, including distributed objects and their as- 
sociated data and instructions, for processes currently 
operating on processor 202. ROM typically includes ba- 
sic operating instructions, data and objects used by the 
computer to perform its functions. In addition, a second- 
ary storage device 208, such as a hard disk, CD ROM, 
magneto-optical (floptical) drive, tape drive or the like, 
is coupled bidirectionally with processor 202. Second- 
ary storage device 208 generally includes additional 
programming instructions, data and objects that typical- 
ly are not in active use by the processor, although the 
address space may be accessed by the processor, e.g., 
for virtual memory or the like. Each of the above de- 
scribed computers further includes an input/output 
source 210 that typically includes input media such as 
a keyboard, pointer devices (e.g., a mouse or stylus) 
and the like. Each computer can also include a network 
connection 212. Additional mass storage devices (not 
shown) may also be connected to CPU 202 through net- 
work connection 212. It will be appreciated by those 
skilled in the art that the above described hardware and 
software elements, as well as networking devices, are 
of standard design and construction. 

The computer-implemented methods described 
herein can be implemented using techniques and appa- 
ratus well-known in the computer science arts for exe- 
cuting computer program instructions on computer sys- 
tems. As used herein, the term "computer system" is de- 
fined to include a processing device (such as a central 
processing unit, CPU) for processing data and instruc- 
tions that is coupled with one or more data storage de- 
vices for exchanging data and instructions with the 
processing unit, including, but not limited to, RAM, 



ROM, CD-ROM, hard disks, and the like. The data stor- 
age devices can be dedicated, i.e., coupled directly with 
the processing unit, or remote, i.e., coupled with the 
processing unit, over a computer network. It will be ap- 
5 preciated that remote data storage devices coupled to 
a processing unit over a computer network can be ca- 
pable of sending program instructions to a processing 
unit for execution on a particular workstation . In addition, 
the processing device can be coupled with one or more 
additional processing devices, either through the same 
physical structure (e.g., in a parallel processor), or over 
a computer network (e.g., a distributed processor.). The 
use of such remotely coupled data storage devices and 
processors will be familiar to those of skill in the compu- 
ter science arts. The term "computer network" as used 
herein is defined to include a set of communications 
channels interconnecting a set of computer systems 
that can communicate with each other. The communi- 
cations channels can include transmission media such 
as, but not limited to, twisted pair wires, coaxial cable, 
optical fibers, satellite links, or digital microwave radio. 
The computer systems can be distributed over large, or 
"wide" areas (e.g., over tens, hundreds, or thousands of 
miles. WAN), or local area networks (e.g., over several 
feet to hundreds of feet, LAN). Furthermore, various lo- 
cal- and wide-area networks can be combined to form 
aggregate networks of computer systems. One example 
of such a confederation of computer networks is the "In- 
ternet". 

Figure 4 at 400 illustrates schematically one em- 
bodiment of a system for composing and installing ob- 
ject-oriented applications in a distributed object system. 
The illustrated system includes a composition builder 
402 which the user, typically a programmer, employs to 
compose applications for installation on the distributed 
object system such as that shown in Figure 1 described 
above. The composition builder is coupled with a com- 
ponent service 404, described in greater detail herein- 
below, that provides the user or programmer access to 
objects available on the distributed object system. Com- 
position builder 402 is further coupled to a code gener- 
ator 408 which, in conjunction with program template re- 
pository 406, takes the composition created by the com- 
position builder and produces program source files as 
shown at 410. 

Programs source files 410 are then forwarded to 
ODF compiler/linker 414. In addition. ODF compiler/link- 
er 41 4 is coupled with object access software 412 which 
object access software is coupled with component serv- 
ice 404. Object access software 41 2 comprises a set of 
stubs that are produced when an IDL compiler is used 
to prepare an language mapping for an IDL interface in 
accordance with OMG CORBA specifications for the 
construction of distributed objects. ODF compiler/linker 
41 4 produces both object software 41 6 and network ap- 
plications 41 8 which in turn access network objects 422 
as shown generally at 420. These network objects can 
then employed by the object access software 41 4 either 
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for use in the catalogue service 404 or in conjunction 
with ODFcompiler/l inker 41 4as indicated by the dashed 
arrows. 

2. LIBRARIES OF COMPONENTS REPRESENTING 
DISTRIBUTED OBJECTS TO FACILITATE RE-USE OF 
DISTRIBUTED OBJECTS 

In one aspect, the present invention provides a de- 
velopment environment and devices adapted to facili- 
tate the re-use of distributed object code in a distributed 
object system. An illustration of one embodiment of such 
an environment is provided at 500 in Figure 5, which 
illustrates a hierarchical directory structure through 
which users (typically programmers) can browse, exam- 
ine, and access components that represent distributed 
objects available for re-use across the distributed object 
system. Thus, it will be recognized that using the hier- 
archical directory structure and library such as illustrat- 
ed in Figure 5 programmers will have access to code 
located at various points throughout the distributed ob- 
ject system through a central library of references to that 
code. 

Referring now to hierarchical directory structure 
500 in greater detail, it will be appreciated by those of 
skill in the art that the illustrated structure is represent- 
ative of a naming service commonly used in distributed 
object systems. At 502 a workgroup root directory is de- 
fined, from which root directory 502 extends subdirec- 
tories defining contexts such as context 504. A particu lar 
context is a Services context shown at 506 from which 
Services context extends various subdirectories indicat- 
ing services available on the network including Compo- 
nent service 508. From Component service subdirecto- 
ry 508 extends various services and components such 
as Library Service 510, Components subdirectory 512 
and Incidental Objects subdirectory 514. Components 
subdirectory 512 includes a Naming context subdirec- 
tory 516 from which extends the individual components 
that represent distributed objects throughout the distrib- 
uted object system such as shown at 51 8, 520 ; and 522. 

Library service 510 is in communication with vari- 
ous Catalog clients, such as shown schematically at 
524, through which users of the system access the Li- 
brary Service to locate and access components such as 
those at 518, 520 and 522. In one embodiment, Library 
Service 510 manages Components subdirectory 512, 
and its subdirectories, as indicated by the dashed box 
at 524. Thus, in this embodiment the Library Service al- 
lows the user access to all of the components within the 
Components subdirectory 512 thereby providing a cen- 
tral location across which components can be searched 
and their related distributed objects identified and ob- 
tained for re-use in the development of new distributed 
object applications. In one embodiment, the Library 
Service is an distributed object acting as a server to pro- 
vide a single "librarian" for the components, thereby giv- 
ing consistency and managed access for multiple users 



across the network. In a particular embodiment, the li- 
brary service provides both a file system and a query 
interface through which the names and various aspects 
of the components, such as their interfaces, can be 
5 searched by a user. 

In the embodiment illustrated in Figure 5 ; the 
present invention utilizes component objects (also re- 
ferred hereinbelow to as "components") that represent 
distributed objects in the system. The components are 
10 made available through, e.g., Library Service 510 using 
Catalog Client 524, for users to search and browse to 
determine the nature of the distributed objects related 
to the components. It will be appreciated by those of skill 
in the distributed computing arts that such an arrange- 
rs ment offers advantages over a system in which refer- 
ences are made directly to the distributed objects. In 
particular, the distributed objects by their very nature are 
highly transient entities. In some case these objects are 
being modified and moved within the system so that it 
20 is difficult for any sort of library service, such as shown 
at 510, to maintain a record of the location of each dis- 
tributed object without incurring large computational 
overhead. 

It will also be appreciated that in a typical browsing 
25 action the user does not necessarily require access to 
the entirety of the distributed object immediately. Typi- 
cally, the user is seeking more general information about 
the basic nature of the object and how the code within 
that object is used so that they may determine whether 
30 they desire access to the underlying distributed object 
in their code. In one embodiment, the present invention 
satisfies these needs by providing components that rep- 
resent the build time descriptions of the distributed ob- 
ject to which each component refers. Thus, it will be rec- 
35 ognized that the components provided by the invention 
act as place holders for distributed objects. The actual 
objects can be accessed at appropriate times during the 
construction of new applications. 

In one embodiment, the components themselves 
40 are objects and therefore are defined by an interface, 
such as an IDL interface, that provides the user with a 
description of the attributes and operations that define 
the available services provided by the underlying dis- 
tributed object. In a particular embodiment, each com- 
45 ponent provides presentation information about the dis- 
tributed object. In general, this information can be any 
information which helps to describe the screen pres- 
ence of the distributed object being referred to by the 
component. Such presentation information includes, but 
50 is not limited to, the identity of any icon or icons used to 
identify the object on the distributed object system and 
any names used to refer to the distributed object. In one 
embodiment; two names are provided for each distrib- 
uted object: a short name and a long name. The short 
55 name can be used, for example, by the file system to 
identify the object while the long name can be a more 
descriptive name to assist in the browsing and under- 
standing of the nature of the object. Other types of pres- 
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entation information include, but are not limited to, var- 
ious icons used to reflect the state of the object (e.g., 
icons reflecting selected and deselected states, error 
states, and object type) as well as sounds. 

In addition, in the described embodiment each com- 
ponent includes programmer information to assist the 
user or programmer in understanding the character of 
the code in the underlying distributed object. In one such 
embodiment, the programmer information comprises a 
data sheet provided in a suitable format, such as rich 
text format (RTF) or hypertext markup language 
(HTML), which is embodied in a data stream that is kept 
within the component. As will be familiar to those of skill 
in the distributed computing arts, a data stream is an 
array of bytes that are stored within an object and for- 
warded in response to requests for the information con- 
tained within the array. It will be appreciated that such 
an arrangement is advantageous over a file-based ref- 
erence system as the need for hard addressing of files 
is eliminated. However, it will also be appreciated that a 
file-based method of providing data sheets is compati- 
ble with the scope of the present invention. Such an al- 
ternate embodiment could also be implemented by in- 
cluding pointers to files kept in a database. Examples of 
the types of programmer information contained in the 
data sheet include keywords to allow to facilitate search- 
ing across the library of components for components 
representing objects having certain characteristics, and 
"hard" information that provides the user with data for 
compiling and using the underlying software. 

In one embodiment, the hard information contained 
in the programmer information data sheet includes ; but 
is not limited to, the interface definition of the underlying 
object, the factory interface definition for the object, the 
name or names of the methods used to acquire instanc- 
es of the underlying object (e.g., the factory method 
name), the service name of the factory that is installed 
when the object is created, and the various plugs, sock- 
ets and properties that are available in the underlying 
distributed object. In addition, various installation infor- 
mation is included with the data sheet such as the 
names of header files for both the object and interface 
definitions of the distributed object, the locations of the 
header files, information describing necessary prereq- 
uisites to obtain the code required to compile and build 
the object as well as macro definitions and compiler in- 
formation. 

Components can be constructed using a variety of 
methods. In one embodiment, the components are con- 
structed during the building, packaging, and installation 
process performed when the object is constructed. In 
this embodiment, a populator mechanism is used to take 
a text representation of the component data which is ex- 
tracted from the object during the build and packaging 
stages to define and install the corresponding compo- 
nent automatically. It will be appreciated by those of skill 
in the programming arts that such a process greatly fa- 
cilitates the re-use of code by making the generation of 



components relatively transparent to the programmer 
by relieving the programmer of the need to consciously 
construct a component by hand or otherwise initiate a 
separate process for the building and installation of 

5 components. Alternatively, the component can be con- 
structed in a similar fashion through a builder using a 
mechanism similar to that just described. In still another 
embodiment the component interface can be defined 
through a service offered by the distributed object sys- 

10 tern so that a programmer can incorporate the service 
through the inheritance structure of the distributed ob- 
ject such that users can call on an object to have a com- 
ponent built from the object itself. Such an embodiment 
offers the advantage of providing programmers custom- 
's izable methods of constructing components. The 
above-described methods can be implemented using 
standard techniques known to those of skill in the object 
programming arts and especially those of skill in the dis- 
tributed object programming arts. 

20 One embodiment of catalog client 524 is illustrated 
at 600 in Figure 6. This embodiment is an illustration of 
a graphical user interface (GUI) that can be incorporated 
with a visual application builder. Figure 6 illustrates a 
cataloger 600 which includes a header bar 602, a con- 

25 text browser 604, a separator region 606, a component 
catalog viewer 608, a second separator region 61 0, and 
a detail viewer region 612. Within header region 602 are 
contained buttons 614, 616, 618 and 620. In one em- 
bodiment buttons 614 and 616 control the display in re- 

30 gjon of 604. For example, depressing button 614 pro- 
vides the illustrated browser view while depressing but- 
ton 616 provides a query window into which query win- 
dow search terms and other search parameters may be 
entered so that region 524 of Figure 5 can be searched 

35 for components having desired properties. Similarly 
buttons 618 and 620 in one embodiment are used to 
control the display of region 612. For example, button 
618 when depressed can provide a view of data sheets 
for components that are selected in region 608 while, if 

40 button 620 is depressed, the representation of compo- 
nents that incorporate a component selected in region 
608 is displayed. 

In the illustrated embodiment, in which region 604 
provides a browser over which the context hierarchy 

45 such as shown in region of 524 of Figure 5 is shown, the 
user is presented with various columns 622, 624, 626, 
and 628 which contain the various contexts and subcon- 
texts of the context structure. In the illustrated example, 
region 622 contains the contexts "Demo" 630. "Printing" 

50 632 and "Math" 634. These represent the higher levels 
of the context hierarchy. In the illustration the context 
"Printing" 632 is shown as being selected, as indicated 
by the highlighted region surrounding that particular 
context. Within region 624 are shown those subcontexts 

55 that are directly subordinate to the selected context 632. 
These subcontexts include various printer types such 
as "Daisywheel" 635, "PostScript" 636 ; and "Line Print- 
er" 637. A selection of "PostScript" context 636 provides 



8 



15 



EP 0 817 032 A2 



16 



a second set of subcontexts which depend directly from 
the PostScript selection as shown in region 626. These 
subcontexts include the selections "Sun", "Apple", "IBM" 
and "HP". The PostScript type "Sun" is illustrated as be- 
ing selected. In the illustrated example, the choices in 
region 626 represent the lowest subcontext in the par- 
ticular region of the context hierarchy being shown and, 
therefore, region 628 is empty. However, were the sub- 
context selected in region 626 to have subordinate sub- 
contexts those subcontexts would appear in region 628. 

Once a selection is made in region 626 (or the re- 
gion listing the lowest-level contexts of the context hier- 
archy) a display of all components available within that 
subcontext are displayed in region 608 (in the case 
where the appropriate display alternative is selected). 
These components include "PS Printer" component 640 
and shown as highlighted by highlighting box 642 and 
"Line Printer" component 644 (not highlighted). The se- 
lection of "PostScript" component 640, as indicated by 
border 642, provides a display of the data sheet "PS" 
646 in region 612 (again, in the case where the appro- 
priate display alternative is selected). In one embodi- 
ment, regions 604, 608, and 612 are scrollable so that 
information that extends beneath separator regions 
606, 610, and the lower end of the window at 612, can 
be observed by the user. The construction of such a win- 
dow can be performed using techniques and software 
familiar to those of skill in the art of graphical user inter- 
face programming. Typically operating systems for con- 
structing GUI interfaces include ; but are not limited to, 
OpenStep (available from Sun Microsystems, Mountain 
View, CA) ; X Windows (X Consortium, Cambridge, MA), 
Windows (Microsoft Corporation. Redmond. WA) and 
the Macintosh operating system (Apple Computer, Cu- 
pertino, CA). 

The use of components, and the information and 
links they contain to the underlying objects they repre- 
sent, greatly facilitates not only the location of existing 
code for re-use. but also the development of distributed 
object applications by relieving the programmer or user 
of the burden of providing the large amounts of boiler- 
plate computer code required for the basic housekeep- 
ing functions necessary for objects to be installed on the 
distributed object system. Components presented 
through the component catalog to the user can be ma- 
nipulated graphically and placed into worksheets in 
which compositions comprising parts derived from the 
components contained in the catalog representing var- 
ious existing distributed objects, modified distributed ob- 
jects, or original distributed objects, are connected to 
define thereby new applications to be installed on the 
distributed object system. The use of the programmer 
information, and especially information relating to the 
plugs, sockets, and properties of the underlying objects 
represented by the components, is especially useful in 
such systems as the user then can graphically intercon- 
nect the plugs and sockets of various components (or 
their representations as parts) to define relationships 



among the distributed objects which will ultimately de- 
fine the distributed object application without extensive 
examination of the underlying distributed object's code 
and the creation of large amounts of standard coding 

5 required to establish relationships among objects. 

Furthermore, once the distributed application has 
been defined using the information available in the com- 
ponents and through their graphical interconnections (e. 
g., as their derivative parts), a code generator facility 

10 (such as shown at 408 is Figure 4) then retrieves the 
references contained in the programmer information 
such as the factory IDL interface definitions, the names 
of methods used to acquire instances of objects (i.e. fac- 
tory method names), service names for factories that 

15 are installed, header files, source code locations, macro 
definitions, and compiler information, to generate auto- 
matically the boilerplate code that is required to define 
the application as a distributed application and install 
that distributed application on the distributed object sys- 

20 tern. 

Thus it will be seen from the foregoing that the 
present invention substantially addresses the needs of 
distributed object programmers for systems that facili- 
tate the reuse and generation of code. Using the com- 

25 ponent services described herein, programmers can 
quickly identify and access distributed objects that have 
already been developed and installed on the distributed 
object system. The ability to easily browse and select 
existing distributed objects in a highly communal fashion 

30 as provided by the centralized library service and hier- 
archical directory structure described herein increases 
the sense of "community" among programmers by pro- 
viding a central repository for their code which can be 
examined and incorporated into ongoing software de- 

35 velopment projects. By using components which not on- 
ly provide information regarding the identity, composi- 
tion, and use of the distributed objects which the com- 
ponents represent, but also include references required 
to construct the necessary boilerplate code to install 

40 software on a distributed object system, the tedious 
work of hand-coding such boilerplate is largely removed 
from the programmer; thus, allowing the programmer to 
focus on the more creative problems with respect to de- 
veloping and installing software on a distributed object 

45 system. 

It will be appreciated by those of skill in the program- 
ming arts, and especially the distributed programming 
arts, that the various methods and devices described 
herein can be implemented in a large variety of ways 

50 without departing from the scope of the present inven- 
tion. In particular, it is noted that various hierarchical di- 
rectory structures other than that illustrated in Figure 5 
can be employed without departing from the present in- 
vention. In addition it is further noted that a variety of 

55 graphical user interfaces can be provided in addition to 
that shown in Figure 6 herein. For example, browser 604 
can be adapted to show both the context hierarchy and 
the individual components. Also, additional windows 
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can be added to the catalog interface to provide view for 
both data sheets and component relationships in a sub- 
stantially non-modal fashion. Finally the composition of 
components may include more, or less information than 
described herein. 



Claims 

1 . A computer-implemented method for selecting and 
reviewing a distributed object installed on a distrib- 
uted object system, comprising the steps of: 

a) generating a library of components corre- 
sponding to distributed objects on said distrib- 
uted object system, said library of components 
including one component corresponding to said 
distributed object, wherein each of said compo- 
nents includes information describing the dis- 
tributed object to which said component corre- 
sponds; 

b) displaying the contents of said library using 
a catalog interface device; 

c) browsing said library of components using 
said catalog interface device to identify said 
component corresponding to said distributed 
object; 

d) selecting said component corresponding to 
said object; and 

e) displaying at least a portion of said informa- 
tion describing said distributed object. 

2. The computer-implemented method of claim 1, 
wherein said step of displaying the contents of said 
library comprises providing a display of at least a 
portion of the hierarchical directory structure of said 
library. 

3. The computer-implemented method of claim 2, 
wherein said step of browsing said library of com- 
ponents comprises selecting a file path using said 
display of said hierarchical directory structure of 
said library and displaying representations of com- 
ponents located in said path. 

4. The computer-implemented method of claim 3, 
wherein said representations comprise icons, and 
said step of selecting comprises making a selection 
action on an icon. 

5. The computer-implemented method of any of 
claims 1-4, wherein said information includes pres- 
entation information, programmer information, and 
tool information for the object corresponding to said 



component. 

6. The computer-implemented method of any of 
claims 1-5, further comprising the step of generat- 

s ing said component corresponding to said distribut- 

ed object. 

7. The computer-implemented method of claim 6, 
wherein said step of generating comprises activat- 

10 ing a component service supported by said distrib- 
uted object. 

8. The computer-implemented method of claim 6, 
wherein said step of generating said component 

15 comprises generating said component when said 
object is installed on said distributed object system. 

9. The computer-implemented method of claim 6, 
wherein said component is generated when said 

20 object is built. 

10. A computer system for selecting and reviewing a 
distributed object installed on a distributed object 
system, comprising: 

25 

a) a library of components corresponding to dis- 
tributed objects on said distributed object sys- 
tem, said library of components including one 
component corresponding to said distributed 

30 object, wherein each of said components in- 

cludes information describing the distributed 
object to which the component corresponds; 

b) a library manager which is effective to locate 
35 and retrieve said components: and 

c) a catalog interface device for displaying, re- 
viewing and selecting said components in said 
library, said catalog interface device being cou- 

40 pled with said library manager such that queries 

and selection actions made in said catalog in- 
terface device are communicated to said library 
manager. 

45 11. The computer system of claim 10, further compris- 
ing a component generator which is effective to gen- 
erate components corresponding to selected, in- 
stalled distributed objects in said distributed objects 
system. 

50 

12. The computer system of claim 11, wherein said 
component generator is coupled with the distributed 
objects to which said components refer. 

55 13. The computer system of any of claims 11-12, further 
comprising an object development facility coupled 
with said component generator such that said com- 
ponents are generated when the distributed objects 
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to which the components refer are processed by 
said object development facility. 

14. The computer system of any of claims 11-12, further 
comprising a builder coupled with said component s 
generator such that said components are generat- 
ed when the distributed objects to which the com- 
ponents refer are processed by said builder. 

15. The computer system of any of claims 10-14, 10 
wherein said catalog interface device comprises a 
graphical user interface. 

16. The computer system of claim 15, wherein said cat- 
alog interface devices comprises a display of at 15 
least a portion of the hierarchical directory structure 

of said library. 



22. The computer system of claim 21 , further compris- 
ing a component catalog coupled with said library 
service and said input/output device. 

23. The computer system of claim 22 ; wherein said 
component catalog comprises a graphical user in- 
terface. 

24. A computer program product comprising a compu- 
ter-usable medium having computer-readable pro- 
gram code embodied thereon for a component data 
structure, said component data structure being re- 
lated to a distributed object data structure installed 
on a distributed object system, and said component 
data structure including presentation information, 
programmer information, and tool information relat- 
ing to said distributed object data structure. 



17. The computer system of claim 16, wherein said cat- 
alog interface device further includes a display of 20 
representations of said components located in a 
chose file path. 

18. The computer system of claim 1 7, wherein said rep- 
resentations comprise icons. 25 



25. The computer program product of claim 24 ; further 
comprising computer-usable medium having com- 
puter-readable program code embodied thereon for 
effecting the following steps within the computer 
system: 

a) generating said component; 



19. The computer system of any of claims 10-18, 
wherein said components include presentation in- 
formation, programmer information, and tool infor- 
mation for the object corresponding to said compo- 30 
nent. 

20. A computer system comprising: 



b) generating a library of component data struc- 
tures corresponding to distributed object data 
structures on said distributed object system, 
wherein each of said component data struc- 
tures includes information describing a distrib- 
uted object data structure to which the compo- 
nent data structure corresponds; 



a) a processing unit; 35 c) displaying the contents of said library using 

a catalog interface device; 



b) an input/output device coupled with said 
processing unit; 

c) random access memory coupled with said 40 
processing unit; and 



d) browsing said library of component data 
structures using said catalog interface device 
to identify said distributed object data struc- 
tures; and 



d) a memory device in communication with said 
processing unit, said memory device including 
a distributed object reference data structure 45 
and an associated component data structure, 
said component data structure including pres- 
entation information, programmer information, 
and tool information relating to said distributed 
object data structure. so 



21. The computer system of claim 20, further compris- 
ing a library of components contained in a library 
data structure residing in said memory device, said 
library of components including a library service ef- 55 
fective to locate and retrieve said components in re- 
sponse to commands received from said input/out- 
put device. 



e) displaying at least a portion of said informa- 
tion describing said distributed object data 
structures. 

26. The program product of claim 25, wherein said com- 
puter-readable program code generating includes 
code for activating a component service supported 
by said distributed object data structure. 

27. The program product of claim 25, wherein compu- 
ter-readable program code generating includes 
code for generating said component comprises 
generating said component data structure when 
said distributed object data structure is installed on 
said computer system. 



11 



21 



EP 0 817 032 A2 



28. The program product of claim 25, wherein said com- 
ponent data structure is generated when said dis- 
tributed object data structure is built. 
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